Hi Folks, |
Re: Dynamic Traceability Matrix Generation using DXL You can have your wizard, however, calculate how many columns are needed by your module at this time and insert them cleverly, but when links change over time the number of needed columns would need to change, but would not. The multi-column wizard breaks down considerably, partly due to the exponential number of links the further you go out making a column 4 huge, but also because it fails to show the relationships between the columns: I think most folks want to see the 1->2->3->4 relationships. It sure sounds like what you want is a single column, where you recursively following out-links until you come to object S. If you don't care at all about F then you display the T-A-S values. If you do care a little about F, then you can display T->F1->F2-A-S values; or just some number saying how far away S is from T: T-A-S(2). Or, do what I do: make an on-demand script that makes the report you want.
|
Re: Dynamic Traceability Matrix Generation using DXL The answers did raise my hopes. However, what is the ON-DEMAND Script? Do you mean that users should request for one for a module and then you provide them the script.This way you wish to get the exact depth from the user himself!! It might not work for me as each module contains minimum of 200 objects and 100 links even with on-demand script as I still need to know the different depths. Did you ever try to build a loop for say some depth 15 and then BREAK out of loop when you reach an object whose source is Module S. I assume that in my case the depth can never be more than 10, but as a precaution use 15 as depth. Keeping all these aside, there is also an intriguing point in my case which is all links are established using a single link module. Someway this rule haunts me by telling me that Why to look around in each formal module when it is me who contains the information about every link you created in this project. Did this plant any seeds? Thanking You, Kiran C |
Re: Dynamic Traceability Matrix Generation using DXL SystemAdmin - Mon Sep 21 02:36:07 EDT 2009 [1] Triggers: Run when a certain event occurs [2] Layouts: Run when their object is displayed [3] AttrDXL Run once when object is displayed All the above are 'deployed' in the database. [4] are scripts that you run when you want to. I call that 'on-demand'. These are generally deployed in a file system but a reference is inserted in a pull-down menu. So my 'on-demand' reference was suggesting you could write a script that makes a report, and you runn it when you want the report. If I were writing a script to recurively search out-links until I came to an 'S' object or until I re-visisted an object, I would not need to hard-code any depth limitation. It does not make sense to have some super-dynamic script that adjusts the number of depth link analysis columns dynamically. As the depth complexity groes exponentially, having a depth of 4 has always for me produced some huge column that's not realistic to see. 15 depth is as unrealistic as is improving health care in the long run by paying providers less money than their services cost. But I digress... As I said, I don't think you care much about the linked objects between your T and S, so you just need one column; that searches recursively until it finds an S. No, searching the link module is a wrong approach, and besides the link module display gets its informtion from the source-target modules; it does not have the information about each link therein. Links are stored in the source module.
|